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Abstract 
This document identifies and describes the requirements for a set of 
use cases related to Segment Routing network resiliency on Source 


Packet Routing in Networking (SPRING) networks. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are candidates for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8355. 
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Les 


Introduction 


This document reviews various use cases for the protection of 
services in a SPRING network. The terminology used hereafter is in 
line with [RFC5286] and [RFC5714]. 


The resiliency use cases described in this document can be applied 
not only to traffic that is forwarded according to the SPRING 
architecture, but also to traffic that originally is forwarded using 
other paradigms such as LDP signaling or pure IP traffic (IP-routed 
traffic). 


Three key alternatives are described: path protection, local 
protection without operator management, and local protection with 
operator management. 


Path protection lets the ingress node be in charge of the failure 
recovery, as discussed in Section 2. 


The rest of the document focuses on approaches where protection is 
performed by the node adjacent to the failed component, commonly 
referred to as local protection techniques or fast-reroute techniques 
[RFC5286] [RFC5714]. 


In Section 3, we discuss two different approaches providing unmanaged 
local protection, namely link/node bypass protection and shortest- 
path-based protection. 


Section 4 illustrates a case allowing the operator to manage the 
local protection behavior in order to accommodate specific policies. 


In Section 5, we discuss the opportunity for the SPRING architecture 
to provide loop-avoidance mechanisms such that transient forwarding 
state inconsistencies during routing convergence do not lead into 
traffic loss. 


The purpose of this document is to illustrate the different use cases 
and explain how an operator could combine them in the same network 
(see Section 6). Solutions are not defined in this document. 
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Figure 1: Reference Topology 


We use Figure 1 as a reference topology throughout the document. The 
following link metrics are applied: 


o Links from/to A and Z are configured with a metric of 100. 
o CH, GD, DI, and HE links are configured with a metric of 6. 
o All other links are configured with a metric of 5. 


Note: Link metrics are bidirectional; in other words, the same metric 
value is configured at both sides of each link. 


.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Path Protection 


As a reminder, one of the major network operator requirements is path 
disjointness capability. Network operators have deployed 
infrastructures with topologies that allow paths to be computed ina 
complete disjoint fashion where two paths wouldn’t share any 
component (link or router), hence allowing an optimal protection 
strategy. 


A first protection strategy consists of excluding any local repair 
and instead uses end-to-end path protection where each SPRING path is 
protected by a second disjoint SPRING path. In this case, local 
protection is not used along the path. 


For example, a pseudowire (PW) from A to Z can be "path protected" in 
the direction A to Z in the following manner: the operator configures 
two SPRING paths, T1 (primary) and T2 (backup), from A to Z. 
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The two paths may be used: 


o concurrently, where the ingress router sends the same traffic over 
the primary and secondary path (this is usually known as 1+1 
protection); 


o concurrently, where the ingress router splits the traffic over the 
primary and secondary path (this is usually known as Equal-Cost 
Multipath (ECMP) or Unequal-Cost Multipath (UCMP)); or 


O as a primary and backup path, where the secondary path is used 
only when the primary failed (this is usually known as 1:1 
protection). 


Tl is established over path (AB, BC, CD, DE, EZ) as the primary path, 
and T2 is established over path (AF, FG, GH, HI, IZ} as the backup 
path. The two paths MUST be disjoint in their links, nodes, and 
Shared Risk Link Groups (SRLGs) to satisfy the requirement of 
disjointness. 


In the case of primary/backup paths, when the primary path Tl is up, 
the packets of the PW are sent on T1. When T1 fails, the packets of 
the PW are sent on the backup path T2. When T1 comes back up, the 
operator either allows for an automated reversion of the traffic onto 
Tl or selects an operator-driven reversion. Typically, the 
switchover from path T1 to path T2 is done in a fast-reroute fashion 
(e.g., sub-50 milliseconds) but, depending on the service that needs 
to be delivered, other restoration times may be used. 


It is essential that any path, primary or backup, benefit from an 
end-to-end liveness monitoring/verification. The method and 
mechanisms that provide such a liveness check are outside the scope 
of this document. An example is given by [RFC5880]. 


There are multiple options for a liveness check, e.g., path liveness, 
where the path is monitored at the network level (either by the head- 


end node or by a network controller/monitoring system). Another 
possible approach consists of a service-based path monitored by the 
service instance (verifying reachability of the endpoint). All these 


options are given here as examples. While this document does express 
the requirement for a liveness mechanism, it does not mandate, nor 
define, any specific one. 
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From a SPRING viewpoint, we would like to highlight the following 
requirements: 


o SPRING architecture MUST provide a way to compute paths that are 
not protected by local repair techniques (as illustrated in the 
example of paths T1 and T2). 


o SPRING architecture MUST provide a way to instantiate pairs of 
disjoint paths on a topology based on a protection strategy (link, 
node, or SRLG protection) and allow the validation or 
recomputation of these paths upon network events. 


o The SPRING architecture MUST provide an end-to-end liveness check 
of SPRING-based paths. 


3. Management-Free Local Protection 


This section describes two alternatives that provide local protection 
without requiring operator management, namely bypass protection and 
shortest-path-based protection. 


For example, traffic from A to Z, transported over the shortest paths 
provided by the SPRING architecture, benefits from management-free 
local protection by having each node along the path automatically 
precompute and preinstall a backup path for the destination Z. Upon 
local detection of the failure, the traffic is repaired over the 
backup path in sub-50 milliseconds. When the primary path comes back 
up, the operator either allows for an automated reversion of the 
traffic onto it or selects an operator-driven reversion. 


The backup path computation SHOULD support the following 
requirements: 


o 100$ link, node, and SRLG protection in any topology; 
o automated computation by the IGP; and 
o selection of the backup path such as to minimize the chance for 


transient congestion and/or delay during the protection period, as 
reflected by the IGP metric configuration in the network. 
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3.1. Management-Free Bypass Protection 


One way to provide local repair is to enforce a failover along the 
shortest path around the failed component. 


In case of link protection, the point of local repair will create a 
repair path avoiding the protected link and merging back to the 
primary path at the next hop. 


In case of node protection, the repair path will avoid the protected 
node and merge back to the primary path at the next-next hop. 


In case of SRLG protection, the repair path will avoid members of the 
same group and merge back to the primary path just after. 


In our example, C protects destination Z against a failure of the CD 
link by enforcing the traffic over the bypass (CH, HD). The 
resulting end-to-end path between A and Z, upon recovery from the 
failure of CD, is depicted in Figure 2. 


B * * *c------ D * * xE 
* | * / *N / * 
* xf * V * 
A | NEL EE NE 
\ | a ee ie, 
\ | | / NE \|/ 
E------ G------ H------ I 


Figure 2: Bypass Protection around Link CD 
When the primary path comes back up, the operator either allows for 


an automated reversion of the traffic onto the primary path or 
selects an operator-driven reversion. 
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eR 


Management-Free Shortest-Path-Based Protection 


An alternative protection strategy consists in management-free local 
protection that is aimed at providing a repair for the destination 
based on the shortest path to the destination. 


In our example, C protects Z (which the traffic initially reaches via 
CD) by enforcing the traffic over its shortest path to Z and 
considering the failure of the protected component. The resulting 
end-to-end path between A and Z, upon recovery from the failure of 
CD, is depicted in Figure 3. 


B * * *c------ D------ E 
* | $t a (aes Cay aa 
ud EN ADME DE 
A fx /\ Z 
N | | f. 9 AN | ui 
\| | / pur NIE 
p------ G------ H * * *I 


Figure 3: Shortest Path Protection around Link CD 


When the primary path comes back up, the operator either allows for 
an automated reversion of the traffic onto the primary path or 
selects an operator-driven reversion. 


Managed Local Protection 


There may be cases where a management-free repair does not fit the 
policy of the operator. For example, in our illustration, the 
operator may not want to have CD and CH used to protect each other 
due to the bandwidth (BW) availability in each link that could not 
suffice to absorb the other link traffic. 


In this context, the protection mechanism MUST support the explicit 

configuration of the backup path either under the form of high-level 
constraints (end at the next hop, end at the next-next hop, minimize 
this metric, avoid this SRLG, etc.) or under the form of an explicit 
path. Upon local detection of the failure, the traffic is repaired 

over the backup path in sub-50 milliseconds. When the primary path 

comes back up, the operator either allows for an automated reversion 
of the traffic onto it or selects an operator-driven reversion. 


We discuss such aspects for both bypass and shortest-path-based 
protection schemes. 
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4.1. Managed Bypass Protection 


Let us illustrate the case using our reference example. For the 
demand from A to Z, the operator does not want to use the shortest 
failover path to the next hop, {CH, HD}, but rather the path {CG, GH, 
HD}, as illustrated in Figure 4. 


B* * xC ——— € D * * *E 
* * \ J *N f |* 
* * VZV * V * 
A | Kx IS: FRO GS. a 
\ | gh ON we NS i E 
\ | */ \*/ up 
E------ G * * *H------ I 


Figure 4: Managed Bypass Protection 


The computation of the repair path SHOULD be possible in an automated 
fashion as well as statically expressed in the point of local repair. 


4.2. Managed Shortest Path Protection 
In the case of shortest path protection, the operator does not want 
to use the shortest failover via link CH, but rather the traffic 


should reach H via (CG, GH) due to constraints such as delay, BW, or 
SRLG. 


The resulting end-to-end path upon activation of the protection is 
illustrated in Figure 5. 


\| E \|/ VI 


Figure 5: Managed Shortest Path Protection 


The computation of the repair path SHOULD be possible in an automated 
fashion as well as statically expressed in the point of local repair. 


The computation of the repair path based on a specific constraint 
SHOULD be possible on a per-destination prefix base. 
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Loop Avoidance 


It is part of routing protocols' behavior to have what are called 
"transient routing inconsistencies". This is due to the routing 
convergence that happens in each node at different times and during a 
different lapse of time. 


These inconsistencies may cause routing loops that last the time that 
it takes for the node impacted by a network event to converge. These 
loops are called "micro-loops". 


Usually, in normal routing protocol operations, micro-loops do not 
last long and are only noticed during the time it takes the network 
to converge. However, with the emergence of fast-convergence and 
fast-reroute technologies, micro-loops can be an issue in networks 
where sub-50 millisecond convergence/reroute is required. Therefore, 
the micro-loop problem needs to be addressed. 


Networks may be affected by micro-loops during convergence depending 
of their topologies.  Detecting micro-loops can be done during 
topology computation (e.g., Shortest Path First (SPF) computation), 
and therefore techniques to avoid micro-loops may be applied. An 
example of such technique is to compute a path free of micro-loops 
that would be used during network convergence. 


The SPRING architecture SHOULD provide solutions to prevent the 
occurrence of micro-loops during convergence following a change in 
the network state. Traditionally, the lack of packet steering 
capability made it difficult to apply efficient solutions to micro- 
loops. A SPRING-enabled router could take advantage of the increased 
packet steering capabilities offered by SPRING in order to steer 
packets in a way that packets do not enter such loops. 


Coexistence of Multiple Resilience Techniques in the Same 
Infrastructure 


The operator may want to support several very different services on 
the same packet-switching infrastructure. As a result, the SPRING 
architecture SHOULD allow for the coexistence of the different use 
cases listed in this document, in the same network. 
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Let us illustrate this with the following example: 
o Flow F1 is supported over path (C, CD, E) 
o Flow F2 is supported over path (C, CD, I) 
o Flow F3 is supported over path (C, CD, Z) 
o Flow F4 is supported over path (C, CD, Z) 
It should be possible for the operator to configure the network to 
achieve path protection for F1, management-free shortest path local 
protection for F2, managed protection over path {CG, GH, Z} for F3, 
and management-free bypass protection for F4. 

7. Security Considerations 
This document describes requirements for the SPRING architecture to 
provide resiliency in SPRING networks. As such, it does not 
introduce any new security considerations beyond those discussed in 
[RFC7855]. 

8. IANA Considerations 
This document has no IANA actions. 

9. Manageability Considerations 
This document provides use cases. Solutions aimed at supporting 
these use cases should provide the necessary mechanisms in order to 
allow for manageability as described in [RFC7855]. 
Manageability concerns the computation, installation, and 
troubleshooting of the repair path. Also, necessary mechanisms 
SHOULD be provided in order for the operator to control when a repair 


path is computed, how it has been computed, and if it’s installed and 
used. 
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